home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 824 < prev    next >
Internet Message Format  |  1994-08-27  |  16KB
  1. Date: Sun, 17 Jul 1994 13:10:23 -0400 (EDT)
  2. Date: Sat, 16 Jul 94 02:34 EST
  3. Subject: Gem List (fwd)
  4. Subject: Gem List
  5. Subject:  Re: Buttons Buttons Buttons
  6. Subject:  Re: Buttons Buttons Buttons
  7. Subject:  Re: Online Help
  8. Subject:  Digest
  9. Subject:  RE: Re: Buttons Buttons Buttons
  10. Subject:  Re: RE: Re: Buttons Buttons Buttons
  11. Subject:  Re: Dialogs & Extra Buttons
  12. Date: Sun, 17 Jul 1994 13:10:23 -0400 (EDT)
  13. Mime-Version: 1.0
  14. Precedence: bulk
  15.  
  16. Forwarded message:
  17. >From 0006795560@mcimail.com Sat Jul 16 03:37:08 1994
  18. Date: Sat, 16 Jul 94 02:34 EST
  19. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  20. To: ems <gem-list-approval@world.std.com>
  21. Subject: Gem List
  22. Message-Id: <50940716073405/0006795560PK2EM@mcimail.com>
  23.  
  24. Subject:  Re: Buttons Buttons Buttons
  25.  
  26. Warwick:
  27. -------- 
  28. >Ofir Gal wrote:
  29. >>2. Holding the right button allows clicking in background windows with the
  30. >>   left button, very useful and also the standard behaviour. Works very
  31. >>   well in the desktop and Papyrus is another example where you can move
  32. >>   the cursor around and even select text while in the font selector.
  33. >This is an incredible waste of a button.  It also violates the principle
  34. >of not requiring the user to hold down multiple buttons to perform an
  35. >action.
  36.  
  37. For once we agree. :-) *NO OTHER GUI* requires a right click combo to
  38. get at background window gadgets. It's a waste of time, and it's a stupid
  39. design. It wastes a button that could otherwise be used for something
  40. more useful like a *tool*, rather than *wasting* it on background buttons.
  41.  
  42. >>3. Allow the right button to be used on background windows without topping
  43. >>   them. I personally find this very useful and implemented it in my
  44. >>   toolkit as a user option. It is also used in Datalite and Ease where
  45. >>   you can move/copy/drag files without having to top windows.
  46. >Totally confusing.  All you need to do is allow the user to use the window
  47. >title, or any unused area of the window to top the window.  In an extreme
  48. >case, also allow a meta key, such as Alt-Ctrl to make the left button top
  49. >the window.
  50.  
  51. My philosophy is that there should be *NO DISTINCTION ON BUTTON 
  52. FUNCTIONALITY* whether a window is in the 'background' or 'foreground'. The
  53. *SAME BUTTONS* should work on the *SAME WINDOW* whether it's topped or not.
  54. Changing the mouse buttons required to click a gadget in the *SAME WINDOW*
  55. depending on its level in the window stack gets totally confusing.
  56.  
  57. >I have my WINCOLOURS set up so that the top window is very little different
  58. >to untopped windows (just the title text changes colour).  This infatuation
  59. >GEM has with topping windows is something we should be getting away from,
  60. >not setting in stone standards.
  61.  
  62. Agreed. If the appearance doesn't change, why require a change in mouse
  63. button behaviour?
  64.  
  65. >If you use MultiTOS, you'll soon become tired of topping windows if you
  66. >move back and forth between applications, and if you have a large enough
  67. >screen to have multiple non-overlapping application windows.
  68.  
  69. This is even more apparent in Windows where MDI applications have children
  70. windows in their main window. Under normal Windows if you click on one
  71. of those child processes, you'll bring the whole damned parent application
  72. *AND ALL OF ITS CHILD WINDOWS* to the top. This is totally stupid, especially
  73. if you're trying to do something productive.
  74.  
  75. There is a PD patch program called (interestingly enough) 'WinX' (no, this
  76. is not the same WinX as on the Atari, it is by a different person) for
  77. Microsoft Windows, and it allows you to activate background window gadgets
  78. without having to top them first. This is very very useful, i.e. you've got
  79. a word processor open, and file manager with 3 or 4 child windows. I can keep my
  80. word processor window topped and scroll the background child windows up and
  81. down to reference files for a document I'm writing. If I had to keep topping
  82. and untopping applications, the job would take 10 times longer.
  83.  
  84. WinX also lets you keep the keyboard 'focus' on a certain application if you
  85. like, so you can background a word processor window and still keep typing
  86. into it. Not exactly useful, but.... :-)
  87.  
  88. It also has an option to automatically top windows that the mouse enters,
  89. but I find this 'feature' annoying as hell. Fortunately WinX allows you to
  90. turn this off.
  91.  
  92. It also has a nice feature in that you can mark a window as 'always topped'
  93. so that it can never be obscured. This is nice for programs which don't have
  94. such a feature internally.
  95.  
  96. WinX also lets you 'pull' any window forward one level, or push it back
  97. one level (or all the way to the back), without having to 'top' it first.
  98. This is handy for rearranging the window stack without having to un-top the
  99. application you're currently using.
  100.  
  101. My philosophy is, the functionality of the GUI should not get in the way
  102. of the user, it should make life EASIER for the user, not more difficult.
  103.  
  104. --Dan Hollis
  105. ----------
  106. Subject:  Re: Buttons Buttons Buttons
  107.  
  108. >>This is an incredible waste of a button.  It also violates the principle
  109. >>of not requiring the user to hold down multiple buttons to perform an
  110. >>action.
  111. >I totally disagree, I wouldn't want Papyrus to work in any other way. It
  112. >doesn't violate anything, this is the way the desktop has behave[d] for the
  113. >last 5 years.
  114.  
  115. Just because the desktop does it that way doesn't mean it's the right way.
  116.  
  117. The desktop allocates all of RAM for even a 0 byte file copy, but you would
  118. think this is the right way to do things simply because the desktop does it?
  119.  
  120. MS-DOS is limited to 640k, but this does not mean that Microsoft is correct
  121. in their design. But you would argue that a 640k limit is perfectly
  122. acceptable just because it's been that way for 8 years.
  123.  
  124. >>>3. Allow the right button to be used on background windows without topping
  125. >>Totally confusing.  All you need to do is allow the user to use the window
  126. >>title, or any unused area of the window to top the window.  In an extreme
  127. >>case, also allow a meta key, such as Alt-Ctrl to make the left button top
  128. >>the window.
  129. >Why? And what is an 'unused' part of a window?
  130.  
  131. Actually it should be : 'click' TOPS a window
  132.                         'press' ACTIVATES a window gadget
  133.  
  134. Is this so difficult to understand?
  135.  
  136. >What has mouse button response to do with screen resolutions? All the
  137. >programs I have run happily in 880*656 and still manage to follow this
  138. >standard mouse behaviour.
  139.  
  140. Atari's "standards" are not always the correct ones. Besides the fact
  141. that atari did not 'declare' the mouse button behaviour as a standard --
  142. it is still open to interpretation.
  143.  
  144. --Dan Hollis
  145. ----------
  146. Subject:  Re: Online Help
  147.  
  148. >>Has any discussion gone into a standard for online help on the GEM
  149. >>list yet?
  150.  
  151. IMHO, PureC's help system is acceptable. Programs like CoNnect have
  152. similar help systems, but IMHO CoNnect goes a little overboard :-)
  153.  
  154. >>I remember some mentions of 1st Guide, but that was lost in the tidal wave
  155. >>of keyboard shortcut discussion...
  156. >We have started talking about this. There are several items that need
  157. >further discussion:
  158.  
  159. >Non-modal dialogues
  160.  
  161. Modal dialogs (i.e. do_alert) should be avoided in 99.9999% of cases.
  162. 'modal' dialogs should be modal for only 1 application (i.e. windowed
  163. modal dialog) and should NOT stop task switching for other applications.
  164.  
  165. Only catastrophic errors (i.e. virtual memory manager crashes, etc. :-)
  166. should bring up a system-wide modal dialog (i.e. do_alert). If some program
  167. brings up a 'printer not connected' alert box, your background BBS program
  168. will halt. This is totally unacceptable.
  169.  
  170. >Palette handling
  171.  
  172. Simple. First 16 colors are 'reserved' standard colors that any application
  173. can depend on NOT changing. The remaining colors can be changed by any
  174. application. It would be nice if there were some standard method where
  175. programs could 'allocate' colors they needed, but this is not possible with
  176. the normal VDI.
  177.  
  178. >keyboard shortcuts config file
  179.  
  180. This *DOES* need discussion. It is a very very good idea, IMHO -- let the
  181. users choose whatever damn key equivalents they want. They can customize
  182. the key equivalents to their own local country keyboard.
  183.  
  184. >right mouse button behaviour
  185.  
  186. Should be a non-issue, IMHO. The same mouse buttons should have